1. Field of the Invention
The present invention relates generally to interfaces which provide access to On-Line Transaction Processing (OLTP) systems from a Web browser, and more particularly, to such interfaces which allow application programs written in the Java programming language to initiate service calls to, and process results returned from, services resident on the OLTP systems.
2. Description of the Prior Art
The methods by which companies conduct business with their customers are undergoing fundamental changes, due in part to World Wide Web technology. This same technology, which makes a company accessible to customers around the world, may also be used on internal company networks to complete operational and administrative tasks.
One of the technologies within the World Wide Web is the Web browser. Web browsers are quickly becoming a de facto user interface standard to the World Wide Web because of their ability to interpret and display information having standard formats (e.g., HyperText Mark-Up Language (HTML), standard text, GIF, etc.). Client software programs, typically referred to as Web browsers (e.g., Mosaic, Lynx, etc.), execute on client systems and issue requests to server systems. Server systems typically execute HyperText Transport Protocol (HTTP) server programs, and process requests received from the Web browsers. While Web browsers are quickly becoming a standard user interface in industry, many businesses still have information maintained and managed by prior art data base management systems such as DMS, RDMS, DB2, Oracle, Ingres, Sybase, Informix, and many others. Furthermore, many database management systems are being utilized as resources within larger transaction processing systems. In view of this, businesses have begun to recognize and capitalize on the growing prevalence of Web browsers in combination with providing access to data stored within their database management systems.
For example, businesses often store many kinds of data within centralized database management systems, such as product sales records, accounting records, and employee information. Often, access to data stored within these database management systems is required to assist in making business-related decisions. Service routines may be resident within the database management systems, and may be called via the Web browser by a user to process and return results based both on input parameters provided and on data stored within the database management system.
Since these service routines must often support a wide variety of requirements, efficiency and flexibility in their execution is desirable. Often, many service routine calls are necessary to achieve a desired result, and thus an interactive or iterative approach is preferred. To achieve this efficiency using the interactive or iterative approach, it is desirable to have the capability to complete additional processing of results returned from the service routine, and make additional service routine calls based on the additional processing.
In one approach, Common Gateway Interface (CGI) programs are used to provide Web browser access to data stored in database management systems. CGI is a standard for interfacing external applications, such as Web browsers, to information servers, such as Web servers. The CGI standard allows programs to be referenced by a Web browser and executed on a Web server system. With this approach, to make a UNIX database accessible via the World Wide Web, a CGI program is executed on the Web server system to transmit information to the database engine, receive results from the database engine, and format the data into an HTML document which is returned to the Web browser. While this approach does make the database accessible via the World Wide Web, the static nature of the HTML interface that the Web browser uses strictly limits the level of interactivity that the user can exercise with the data returned by the database.
Another approach which has been utilized is shown in U.S. patent application Ser. No. 09/033,325, filed Mar. 2, 1998, now U.S. Pat. No. 6,012,067, issued Jan. 4, 2000, entitled: xe2x80x9cTRANSACTION SERVICE INDEPENDENT HTTP SERVER TO TRANSACTION GATEWAYxe2x80x9d, which has been incorporated herein by reference. This approach makes On-Line Transaction Processing (OLTP) systems and their associated databases accessible using HTTP interfaces. With this approach, the OLTP system is accessible to Web browsers by establishing a plurality of transaction gateway clients to receive HTTP requests sent to a Web server from a Web browser. The transaction gateway client establishes a static connection with the OLTP system, and translates between HTTP formatted requests from the Web browser and the request format expected by the OLTP system. This approach saves time by elimination of the prior art steps of connecting with and then disconnecting from the transaction processing system for each request from a browser program.
However, since HTML does not include decisional logic, the Web browser in this approach cannot complete additional processing or manipulate results returned as HTML documents from the OLTP system. This approach also thus does not allow applications executing on the Web browser to manipulate or process data returned from the OLTP service, or allow the applications to make subsequent program calls to the OLTP system based on the processing of returned data.
The present invention overcomes the disadvantages found in the prior art by providing an interface coupled to the Web server which allows a Web browser to initiate service routines resident on On-Line Transaction Processing (OLTP) systems through the interface, and complete additional processing or manipulation of data returned from the service routine.
In a preferred embodiment of the present invention, an interface is provided to allow application programs resident on a Web browser to make program calls to service routines resident on OLTP systems. In the preferred embodiment, these application programs are written in the Java programming language, and are referred to as Java applets. When a user accesses an OLTP system from a Web browser that includes Java applets, the applet may either be resident on the Web browser, or may be copied from the Web server to the Web browser, whereupon the applet is executed. Since Java is a regular programming language that includes decisional capabilities, any data returned from the OLTP program call can be subsequently manipulated by the Java applet, and the Java applet can use the manipulated data to make additional OLTP program calls.
In a preferred embodiment, the application program initiates the service routine through the interface by sending an input request to the server. The interface receives the input request if the input request is of a predetermined type. In the preferred embodiment, the interface receives the request if the input request is from the Java applet. The interface sends an input view definition back to the application program which defines an input data format for the requested service routine. The input view definition may be used to build an input screen on the browser which defines an input data format required to initiate the requested service routine. The input data format defines a number of input fields, each of which may accept input data entries from the user.
Once the input view definition has been received by the application program, and the input data format required for the requested service routine has been used to generate a service request, the application program may execute a service routine on the OLTP system through the interface by sending the service request to the server. The interface receives the service request if the service request is of a predetermined type. In the preferred embodiment, the interface receives the service request if the service request is sent from the Java applet. The interface sends the service request to the service routine where the service routine may perform any number of operations, using the input data provided in the service request, on data stored in the databases within the OLTP system.
In a preferred embodiment, a result of the service routine executing the service request is returned in an output data format to the interface, where the output data format corresponds to the service routine. If the output data format is different from the input data format, the interface sends an output view definition to the application program so that the application program may build an output screen on the browser to view the output results. The output view definition defines the output data format by defining the output fields necessary to display the result on the screen of the browser or to perform further program logic.
In a preferred embodiment, the application program may perform a number of operations on the output result which is in the output data format, and may send another service request to the browser to initiate another service routine. The service request may contain input data entries based on performing a number of operations on the output result returned from the previous service request.